Secure, Audited Processing of Digital Evidence: Filesystem Support for Digital Evidence Bags

Traditional digital forensics methods capture, preserve, and analyze digital evidence in standard electronic containers: images of seized hard drives (e.g., created using the Unix dd command) are stored in regular files and documents are typically processed “as is”. Auditing of a digital investigation, from identification and seizure of evidence through duplication and investigation is essentially ad hoc, recorded in separate log files or in an investigator’s case notebook. Auditing performed in this fashion is bound to be incomplete, because different tools provide widely disparate amounts of auditing information. Over the course of an investigation, a piece of digital evidence may be touched by many different tools, some of which generate no audit trail of their actions (e.g., dd or the command line tools of the Sleuth Kit) and some that generate their own audit logs (e.g., FTK). At the end, an investigator is left to piece together these bits of audit trail to create a comprehensive view of what occurred during the investigation. Digital Evidence Bags (DEBs) are a recently proposed mechanism for bundling digital evidence, associated metadata, and audit logs into a single structure. DEBs categorize the digital evidence they contain and provide a mechanism for associating an audit log that details the investigative processes that have been applied throughout an investigation. DEB-compliant applications can update a DEB’s audit log as evidence is introduced into the bag and as data in the bag is processed. This paper investigates native filesystem support for DEBs, which has a number of benefits over ad hoc modification of digital evidence bags. The first is that some of the advantages of DEBs can be realized even for current generation tools which are DEB-unaware, since a DEB-enabled filesystem can transparently offer the contents of a digital bag to such tools, while automatically updating the DEB’s metadata and audit log. Another advantage, even for DEB-enabled tools, is that the code for updating a DEB, both for introducing and removing items and for updating the audit log, needs to be certified only once. Finally, a stan-